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A Project Management Information System 


□ Our Project Management Information System uses FileMaker to 
handle a variety of needs for a small consulting firm. The FileMaker 
files provide address lists for prospects and clients, contract informa¬ 
tion, personnel records, work in progress/revenue reports, time and 
expense records, invoicing and a ledger. Several files are inter-related 
through lookups and the “import” (“Input from..." in FileMaker II) 
function to minimize data entry effort, move data where needed and 
promote accuracy. 

Descriptions of Fiies □ Prospects: Contains company name, address, contact, phone, and 

marketing information about prosp>ective clients. Each prospect has a 
unique six-character Company Code. 

Proposed: Contains basic company information looked up from the 
Prospects file along with a list of tasks and fees proposed to the pros¬ 
pect. Each proposal is assigned a unique Proposal Number which 
includes the six-character Company Code. 

Clients: This file is nearly identical to the Prosp>ect file with the 
additional information needed for active clients. Uses the Company 
Code established when the client was a prospect. 

Contract: Contains company information looked up from the 
Clients file along with a list of tasks and fees, agreement dates and 
period of performance. Each contract is assigned a unique Contract ID 

number which includes the Company Code. 

Employees: Contains initials, name, 
business address, home address, billing 
rates (client, travel and overhead) and other 
payroll information of all employees and 
consultants. 

Work in Progress (WIP): In the WIP file 
are entered aU employee time charges (both 
overhead and billable) and all client proj¬ 
ect-related expenses along with billing in¬ 
formation. There are three separate layouts 
for data entry, one for each type of record: 
timecard, expense and invoice. All records 
contain the Contract ID number. Billing 
Period Begin Date and an auto-entered 
Record Number. Additionally, timecard 
records include employee initials and cal¬ 
culate the total hours worked on each proj¬ 
ect during the billing period. Expense rec¬ 
ords include the type, amount and a short 
description. Invoice records conteUn invoice 


More about converting from FileMaker II to 
FileMaker Pro. 

1. Most users are having no problems at all, ei¬ 
ther in the conversion process or in using the 
converted files (except for non-working features, 
and sometimes slow speeds). 

2. Of those few for whom the converted file is 
bad, salvation is usually available by going back 
to the original FileMaker II file, compressing it 
and then doing the conversion to Pro. This is not 
possible if there is no longer an original file to 
fall back to. 

3. Of those fewer still for whom the compression 
tactic does not work, try Recover, Compress, 
Convert and ask Claris Tech Support for help. 

A maintenance revision of Pro is expected fairly 
soon. This will be helpful when working In Pro, 
but it may not remove all pain from the conver¬ 
sion process. So make backups of your files and 
convert a copy so you’ll have a fail-back position. 


By 

Sheila Kliewer 
Administrative 
Office Coordinator 
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FLOW OF INFORMATION 










Project MIS 

(continued) 


Flow of Information □ 


The chart on the 
previous page 
shows most of the 
information 
reiationships among 
the severai working 
flies, as weli as 
operation areas. 
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number, date, fees subtotal, expenses subtotal and total Invoice 
amount. 

Invoices: Contains Contract ID number, an auto-entered invoice 
number and date, client information, brief contract description, fees 
with descriptions, project expenses with descriptions, invoice total and 
applied payments. 

Ledger: Every ledger record contains Contract ID number, invoice 
number, and brief description of entry. Additionally, invoice records 
contain the invoice date and fee subtotal, expenses subtotal and total. 
Cash receipt records contain the payment date, check number, fees 
subtotal, expenses subtotal and amount paid. 

The Prospect and Proposal files are used in tandem as are the 
Clients and Contract files. The Clients and Contract files are clones of 
the Prospect and Proposal files, respectively. 

When a company calls and wants information on our consulting 
services, the prosi)ect information (contact, company, address, phone, 
marketing data) is entered into the Prospect file. A six-character Com¬ 
pany Code for the prosp>ect company is assigned and entered. 

If a specific proposal is prepared, that information is entered in 
the Proposal file (type of agreement, description, breakdown of fees by 
tasks, etc.). Prospect information is subsequently looked up from the 
Prospect file based on the Company Code. 

Upon receipt of a signed contract, information from the Prospect 
file is Imported into the Client file and a notation made in the Prospect 
file that the company is now a client. (This notation is to facilitate 
sorting for the “prosjjects only” mailing list for marketing materials.) 
Any information contained in the Client file that is used in another file 
is always looked up using the six-character Company Code. 

The Proposal record (if £iny) is Imported into the Contract file. 
Revisions to the record reflecting the final contract are made. If no 
Proposal record exists, the contract information is entered direcdy into 
the Contract file. At this point a three-part Contract ID code is as¬ 
signed in the Contract file. The first part consists of the Company 
Code, the second is a short code for project type and the third is a 
contract serial number, the Contract ID, which must be unique. When 
time and expense charges are entered into the WIP file and when 
invoices are produced from the Invoice file, the Contract ID serves as 
the lookup key to retrieve the Contract Amoimt in order to error- 
check data entry. If no Contract Amount is found, it raises a flag for 
input error. 

AH overhead categories (internal projects) are treated as separate 
contracts in the Contract file. For example, an overhead Contract ID 
would consist of our own company code, a project type code, and the 
two-digit year. Sample project type codes might be SICK (for sick 
leave), VACN (for vacation), or HOLI (for holidays). This allows a stan- 
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Project MIS 


dard Contract ID code for all entries on the employee timecard. Also, in 
the WIP file we can then track indirect (overhead) labor as well as direct 
client-related time charges. 


(continued) 


_____ □ Employee initials are used as the lookup key when entering time¬ 
card Information in the WIP file. The various billing rates based on 
Employees client, travel and overhead are used in the WIP to calculate overhead 
and client time charges. 


WIP □ This brings us to the central file in the database system: WIP. All 
employee time charges (overhead and client-related) and all client 
project-related expenses are entered into this file. These records, along 
with the Invoices generated from the time and expense records, pro¬ 
vide the basis for detailed contract reporting and employee time track¬ 
ing (vacation, sick leave, etc.). 


Although there are three types of records - time charges, expenses 
and invoices - records share a number of fields in common. The Con¬ 
tract ID code is entered in three parts. This allows lookup of client 
name (Clients) and Contract Amount (Contract) to verify accuracy and 
validity of the Contract ID code. Particularly, if a Contract Amount is 
not found, it serves as a flag for data entry error or the need to update 
the Contract file. 


Enter Initials 


|Ent«r3-patt code 


•Tif 

Rpcord 


■ Period Becin Date 

Enter Hours 

Travel 

* 3150 

Invoice • 


Sum $ 


The second common field is the Billing Period Begin Date. All 
records are part of a particular period (two periods per month, begin¬ 
ning the 1st and the 16th) so detail and summary reports by billing 
period can be run. The third entry is an auto-enter serial number used 
as the Record Number for lookup reference to other files. The last 

standard field is a text field to be 
marked when a contract is finished/ 
closed. This allows rep>orts for “cur¬ 
rent contracts only" by doing a Find 
for the empty Contract Closed field. 
Following is a brief description of the 
individual characteristics of each 
type of record. 


DATA ENTRY SCREEN - TIMESHEETS (SUMMARY) 

Account/Name Client^ Project Rate-Enternon-s>d Contract 


SumOHead i SumBill $ 
+ 


Total Hours 


EXPENSE INPUT CARD 


Enter Period Begin Date: 

Enter 3-Part Code: 

Contract 

Enter Expenses 


E> 9 ense Acct Code 


Expense Amount 


Expense 


Description 


for Invoice 


Record « 3150 

Billing Information 

Date Entered: 1 /7/91 

Invoice Date 


Invoice • 


• Timecard records — The ini¬ 
tials of the employee are used as 
the lookup key. The name and bill¬ 
ing rate (based on client, travel or 
overhead) are looked up from the 
Employee file based on the initials. 
Time charges are calculated using 
the looked-up rate and the num¬ 
ber of hours input. The looked-up 
rate varies automatiCcilly based on 
whether the company code is ours 
or a client’s and whether an indi¬ 
cator for travel has been entered. 
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• Exjjense records — Includes type of exjjense (travel, commu¬ 
nication, materials), amount, and a brief description. The description 
and amoimt are looked up (using the Record Number as the lookup 
key) into the Invoice file when preparing client invoices. 

• Invoice record — The third record type is imported from the 
Invoice file after preparation of the client’s Invoice. It contains the in¬ 
voice niunber, date and amount of fees, expenses, and total billed. 
When an Invoice has been produced, the Invoice number and data are 
also noted on all time and expense records used to generate that in¬ 
voice. Thus, lists of both billed and non-billed time and expenses can 
be run at any time by finding records with either full or empty Invoice 
Number fields. 

Invoice □ The WIP file provides the information needed to generate the in¬ 
voices. The WIP Record Number for each expense to appear on the in¬ 
voice is entered in repeating fields on the Invoice record and the 
amoimt and description of the item is looked up from the WIP. Since 

our work is performed on a fixed-fee 
rather than actual-time basis, the 
time charges in the WIP are only 
used as a guide to determine actual 
billings. This is typical of consulting 
businesses. 

At bUling time (end of the month 
or upwn completion of a contract or 
task), the Inmice fUe is used to pro¬ 
duce invoices. The Date and Invoice 
Number are auto-entered fields. Again, client address information is 
looked up based on the Company Code, and Contract is also looked 
up to verify accuracy of input. The agreement information is entered 
manually as well as a description of what is covered in the billed fee. AH 
totals are automatically calculated. 

After printing the invoice, the invoice record is imported into the 
WIP. The Invoice Number is then indicated on aU WIP time and ex¬ 
pense records used to generate the invoice to indicate that those items 
have been billed and are no longer outstanding. The Invoice record is 
also imported into the Ledger. 

When payments are received they are entered on the invoice rec¬ 
ord. This allows a Find for a listing of outstanding invoices by locating 
those records whose Balance Due does not equal zero. 

Ledger □ The Ledger file contains brief invoice information and cash receipt 

records. Each ledger record represents either an invoice entry or a 
cash receipt entry. All invoice records are imported from the Invoice 
file. Cash receipts are entered manually. This is one of a few areas of 
duplicate memual entry because while Invoices and receipts are on 
separate records in the Ledger file, they are on the same record in the 
Invoice file. So payments are entered manually into the Invoice file as 
well. 


Semi-Monthly Period Start Month of 

INVOICE CARD 

Client Code 

Project Code 

Contract * 

Contract ID • 

Enter X 

When Acct 
Closed 

Fee Descrio 

Record Info 

Record *3150 

Date 1/7/91 

ManExplAcct Code 

Invoice Information Fee Invoiced 

Invoice Date Total Expenses 

Invoice * Total Invoice 


Project MIS 

(continued) 
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-□ Products/Reports 

Project MIS So what good is it to have all this data in the files? How do we get 

useful information out of all this to better manage our contracts? All 
(continued) flies have a basic data entry screen (WTP has three) along with other 

layouts and scripts for running and printing reports. Reports range 
from very simple lists to elaborate summaries and sub-summaries. 
The following reports are produced regularly. 

Prospects — 

• Mailing lists and labels or phone lists for marketing. 

Proposals — 

• List of active proposals for follow-up. 

Clients — 

• Mailing lists and labels or phone lists for marketing. 

Contracts — 

• List of active Contract ID numbers, particularly for use by employees 
in completing their timecards. 

• List of all contracts generated during a period of time, sub-summa¬ 
rized by client and Including total dollar value of all contracts. 

Employees — 

• Address and phone lists. 

• Other pertinent information requested by personnel. 

Invoice — 

• Produces the Invoices actually sent to the client (printed on letter¬ 
head). Three different layouts allow versions for fee and expense, fee 
only and expense only invoices. 

• Provides an end-of-month list of outstanding (unpaid) Invoices by 
client with sub-summaries by client and grand totals. 

• List of all invoices generated during the month indicating those paid 
and those unpaid. These two listings (along with two other reports) are 
used by the bookkeeper to determine monthly revenue. 

• Invoice aging list by date to Identify past due invoices for follow-up. 

Ledger — 

• Provides a detailed ledger card by client by contract showing individ¬ 
ual debits and credits and balance due. 

• Summaiy ledger reports showing total debits and credits and bal¬ 
ance due by contract, with grand totals at the end. 

• A detailed cash receipts listing by client is run at the end of each 
month. This is the third report used by the bookkeeper In determining 
monthly revenue. 

WTP — 

• The fourth report for the bookkeeper is a summary listing by contract 
of all unbilled items (time and expense) at the end of each month. 

• Activity reports by contract, both detail and sirmmaiy, by billing 
period and/or employee. The sub-reports within each contract are 
time charges, expenses, and Invoices, 
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Project MIS 

(continued) 


Quality Control □ 
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- The monthly detailed activity reports allow for monitoring con¬ 
tract expenditures versus budget. We can then make personnel 
and/or contract adjustments based on our review of these activity 
reports. 

- The summary reports at contract close indicate whether our ac¬ 
tual time charges were over or under the fee billed, helping us to 
more accurately bid future projects. 

• Many detail eind summaiy employee time record reports are also 
provided periodically, from vacation and sick leave summary, to total 
hours worked year to date, Including percentage of time spent on 
overhead vs. client projects. 

Due to the complexity of the system and human nature, errors can 
occur. To try to minimize input errors, several lookups are used to 
verify accuracy. For example, when timecards are input into the WIP 
file, the employee name is looked up from the Employee file when the 
employee’s initials are entered. When the Contract ID number is en¬ 
tered in the WIP or Invoices files, the contract amount is looked up 
from the Contract file. When the Customer Code is entered in the 
Contract, WIP or Invoices files, the client name is looked up in the 
Client file. If no text or number appears in the looked up field, it signals 
Input error. 

To insure accuracy when inputting time card hours, after data 
entry a Find is done for employee and period. The computer summaiy 
of hours is checked against the employee time card summary of hours 
and any necessary corrections are made so the two totals are equal. 

Periodically we run a Find for blank employee name, company 
name, and contract amount fields in the WIP, Invoices and Lecher files, 
perform a relookup, run a refind and then scroll through those records 
and make necessary corrections. 

Monthly reports are run from each of the WIP, Invoices and Ledger 
files, as Indicated above. An audit is made of the reports to insure that 
invoices were imported into both the WIP and Ledger files, that cash 
receipts were posted to both the Invoices and Lecher flies, and that the 
time and expense records in the WIP file that have been billed to the 
client in the Ledger file are so Indicated. Corrections are made as 
necessary. 

Another check for errors is made when the manager and I review 
together the corrected month-end reports to monitor contract status 
and determine what billings should be made. 

The final control is the bookkeep>er who uses the monthly reports 
from the WIP, Invoices and Ledger files to produce the revenue and 
bookkeeping reports for management. If her books don’t balance, we 
find and correct the errorfs). 
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Project MIS 

(continuecD 


□ Summary 

Mike Harris (Watertechnics) consulted with us as we developed 
this system. He and 1 spent a considerable amount of time at the 
outset in determining which information should be in which files and 
how the files should be inter-related to make the best use of the data 
and allow for expansion of the system. We ended up with database files 
that are flexible enough for refinements and changes. By setting up 
new report layouts with a few new calculation fields or modifying 
existing layouts, I have been able to provide rep)orts that were not 
anticipated in the initial setup. The system has been able to meet every 
management report request (so far!). _ 


FMR 


Comment - 

Sheila Kliewer’s Project Management Information System is significant for several rea¬ 
sons. The first is that, if her company’s requirements were described as a database problem, 
almost everyone would conclude that this system requires a “relational” database solution. 
Sheila’s accomplishment in FileMaker demonstrates that the computer system does not have 
to do all the work. The “inherently relational” links in her database can be accomplished with 
semi-automatic lookups eind imports. There are even some advantages to avoiding relational 
solutions. Sheila’s procedures involve a natural “posting” system and the files have data 
redundancy (i.e. payments are recorded In three files). Her files are more robust and inde¬ 
pendent than a set of “relational" files. 

There is always the need to think about computer systems as part of a much more 
inclusive “system” of the company Itself: What are the real needs of the organization? Which 
are most important? What are the human resources available? How rapid is employee 
turnover? How much time, money and other resources can the company invest in computers 
and tTcilning, and how soon do they need results? Sheila’s work shows the power and 
necessity of good overall design at the highest levels of the whole system, without which 
FileMaker would have been “inadequate” to this task. 

Sheila’s company spent less than $1500 on outside computer consultants. She spent 
about 400 hours bringing the full system up, including a lot of data entry from older records. 
FileMaker’s flexibility and ease of use in development allows her company to make evolving 
changes quickly, without a debilitating dependence on a consultant for every small modifica¬ 
tion. The overall cost in dollars and time is one-tenth of what a “relational” project would have 
cost. 

Of course, there are dangers and tradeoffs. This FileMaker solution absolutely requires 
competent, dedicated, in-house talent. A full blown “relational” database project might be 
made much more “idiot-prooF. The initial file structure was designed by an experienced con¬ 
sultant (me!) and if the client Inadvertently makes bad decisions during development and 
evolution of the system, some real damage might result. Stfil, Sheila’s remarkable on-going 
success in simplifying an inherently complex bookkeeping problem is a wonderful lesson for 
us all. It proves once again that FileMaker is an end-user’s tool. 

- Mike Harris 
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Locating Characters Ignored by FileMaker 


By 

Joe Kroeger 


□ One of the powerful and defining characteristics of FileMaker, as 
we know, is that it indexes all words, numbers and dates in all fields in 
a database. It does so automatically with no special intervention on 
our part. The result is quick searches and sorts without users needing 
to worry about setting up explicit indexing, as is 
common with most other database products. 


There are no valid criteria in this 
request. Type a ualid request 
before clicking Find, or choose Find 
Rll to browse all the records. 


nn 


There are no ualid criteria in this request. Type 
a ualid request before clicking Find. 


( Cancel ] ^^T^^gainJ 


Nonetheless, at the same time, FileMaker 
does not index punctuation marks and other spe¬ 
cial characters that it considers beneath it’s dig¬ 
nity. Even when they are adjacent to good words. 
Concomitantly, FileMaker ignores punctuation 
entered in a Find request, and if only a punctua¬ 
tion mark is entered, FileMaker ignores it and 
presents one of the ‘Not Valid Re¬ 
quest’ alerts shown to the left. File¬ 
Maker pretends it doesn’t even know 
you typed something into the re¬ 
quest. FileMaker Pro continues this 
same shortcoming. 


FileMaker 
Indexes Everything, 
Except ... 


(FileMaker also uses a couple of 
these un-indexed characters to implement special Find operations. An 
exclamation mark by Itself in a Find request field tells FileMaker to 
locate all records with duplicate contents of indexed material in the 
indicated field. Similarly, an equal sign by itself in a Find request tells 
FileMaker to locate all records in which the indicated field is either 
empty or contains only those Ignored characters.) 


It is not as if FileMaker doesn’t reoRy know that something is in 
the field when you enter punctuation. If you execute a “length” calcu¬ 
lation, for example, all characters in the field are counted by the 
equation - even spaces and those infamous punctuation marks. 


Don't Use 
Punctuation 
for Marking 


Perhaps there is a difficult-to-fix limitation in the present indexing 
design at the heart of FileMaker, and that limitation may make it hard 
to change this characteristic. I have predicted before In these pages 
that one day FileMaker will enter fuUy the grown-up world and will be 
able to handle all keyboard characters. Add it to the Pro wish list. 

But meanwhile there is work to do. We have aU (almost all?) 
learned in our early experience with FileMaker - sometimes painfully - 
not to use punctuation characters as markers. I once had a database 
with a status field that contained one of three characters (A, B or C) to 
indicate the current status of the record. I had a bunch of “B” records 
that had been modified, but they were not quite ready to be promoted 
to “A” status. So I marked them as “B*” figuring that th^ would then 
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Ignored Items 

(continued) 


be easy to locate later for the next stage of work. Oops - FileMaker 
doesn’t know the difference between B and B*; a Find for B* locates all 
records that contain either B or B*. I should have used “BB" or some¬ 
thing else, and these days I do. 

So 1 gave up trying to locate nice characters like $,!, >, *. 

returns and periods. Of course, if I never enter them 1 never have to 
deal with the problems. But If I’ve inherited them when importing a 
bunch of data from an outside source, it can be difficult. 


■□I 



Records: 
51 


FName 

LName 

Organization 

Street 

City 


Joe 

Eroeger 

Elk Horn Publishing 
64 Penny Lane Suite A 
Aromas 


Ell 


State CA Zip 95019 


m Browse 




Return? 

TestChar 





[□I 


FM II Test n 


i 


/ V 





Records: 
51 


Return? 14 
TestChar f " 


M. 


FName 

Joe 

LName 

Eroeger 

Organization 

Elk Horn Publishing 

Street 

64 Penny Lane 

City 

Suite a] 

State 

CA 1 Zip [95019. 


m Browse 




My old technique, when I had a lot 
of data with such characters that 
needed to be changed or removed, was 
to export to a word processor, perform 
the needed changes there, then import 
the information back into the database. 
I have described before in these pages 
(see issue 25. page 13) the process of 
moving data to be edited into a word 
processor. In some cases I was simply 
trying to change such things as ‘P. O. 
BOX’ and ‘P.O. BOX’ to ‘PO BOX’ yet 
FileMaker wouldn’t let me Find records 
that contained pieriods. If there were so 
many records to be changed that it was 
Impractical to do so by hand, it would 
nonetheless be nice to be able to locate 
Just the records with the problems so 
that I could export just the found set 
Instead of the whole database. 

A similar difficulty is those 
naughty, frustrating, unwanted car¬ 
riage returns that sometimes hide in 
one-line fields. These miscreants often 
appear during data entry when a re¬ 
turn character may sometimes get in¬ 
serted instead of a tab, for example. 
You’ll usually notice a field like this 
only when the cursor enters it - the 
field then expands to show the addi¬ 
tional line(s). An out-of-place return 
character like this can wreak havoc 
with reports and mail labels. 

The top figure to the left shows a 
tjqjical simple address file with the 
Suite entered as an extension of the 
street information. The next figure 
down is the same record but with a 
return character entered (by mistake) 


1 


Page 12 Issue 34 


The FileMaker Report 


©1991 Elk Horn Publishing 






























before the “Suite A” information. The extra return can’t be seen in the 
figure, but it is there, lurking in the shadows. Note that it is only when 
the cursor is in the Street field (bottom figure) that the return is 
obvious by inspection. 

Readers John Bedworth and Fred Foote have come up with a neat 
way to detect such return characters. You can’t do a Find to locate 
them because FileMaker won’t let you; their technique for detecting 

these varmints is simply 
a work-around for the 
Find limitation. It is 
done by creating a cal¬ 
culation field that uses 
the Position function to 
detect return char¬ 
acters. Position allows 
the ? character (the re¬ 
turn character) to be en¬ 
tered as a parameter. An 
example equation is 
shown in the figure to 
the left. It really works! 
This calculation was 
used to generate the 
field labeled Return? in 
the figures on the previ¬ 
ous page. fThe 1 charac 
ter is entered into the equation by clicking its button in the equation 
definition dialog. Alternatively, you can enter Option-7 from the key¬ 
board, which enters ? in the Chicago font used In the equation. By the 
way, a 1 inserted in a text equation does not, unfortunately, export as 
a real return cheiracter.) 

Remember that the Position function provides a zero result when 
the specified character is not in the field and a greater-than-zero result 
when it is. The non-zero result also specifies the location of the charac¬ 
ter in the field, counting fi-om the left. Note in the two lower figures on 
the previous page that the Return? field is indicating that a return 
character is located at position 14 In the Street field. 

Easy With this calculation in place, a Find request using >0 in the 

Find Return? field provides a set of all records that contain a return in the 
Street field. This certainly simplifies the problem of eliminating im- 
wanted returns - once they are found it can be easy to delete them 
manually or to export them for external processing. 

This little formula was a nifty insight Bedworth and Foote and 
solved a few problems. So, I figured, if it works for 1, maybe it will work 
for other punctuation as well. And by goUy it does! It turns out that Po¬ 
sition allows us to locate many of the characters that don’t work in the 
Find command. A ’!’ or a for example can be located in the same 


Field Definition 


Return? 


Calculation Result Is: 

OTent (S) Number ODate 


position (Street,"<)l",I)| 


PrefiK 

FName 

LName 

Organization 

Location 

Street 

City 

State 




000 ( 1 ) 

O0©@ 

0000 

0(iD0O 

@00 


= c 

> 

abs 0 



auerage 0 

> 1 


count 0 

< 


date („) 

> ll 


DateToTent 0 

i c 

> 

day 0 




Ka 


OK 


^ [ Cancei ] 
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Ignored Items 

(continuecD 


way as the Just modify the equation, substituting the desired char¬ 
acter for the (And you might want to change the field name from 
Return? to something more appropriate.) Finally. I can Find records 
that contain un-indexed characters. 


The Position technique can be generalized a little by putting the 
character in question into a separate field rather than including it 

within the equation. 
This edlows a single cal¬ 
culation to act as a loca¬ 
tor for any character for 
a given field. I tried it by 
creating another field 
called TestChar. Then I 
changed the equation 
(now called Test?) to 
use the contents of the 
TestChar field instead 
of using an internal con¬ 
stant. The new equation 
is shown in the figure to 
the left. 

With this general¬ 
ized equation, you need 
to (a) Find the records 
you want to test (which could be aU of them), (b) put the character in 
question into the TestChar field and (c) Replace it into all the found 
records. Then you can (d) Find (using >0 in the Test? field) all those 
records that contain the test character. 


Field Definition 


Test? 


Calculation Result is: 

OTeut ® Number O Date 


position (Street,TestChar,1)| 


PrefiH 

FName 

LName 

Organization 

Location 

Street 

City 

State 




0 


0000 

0000 

0O00 

0000 

@00 


= 

0 


abs 0 




auerage 0 

> 



count 0 

< 



date („) 

> 



DateToTeut 0 

< 

0 


day 0 




OK 


[ Cancel"] 


Pre-load the 
Test 
Character 


Multiple 

Characters 

Too 


Test 

Multiple 

Fields 


In this version of the position equation, for some reason, when the 
TestChar field is empty, the Position equation is evaluated to 1 in¬ 
stead of 0. So there may be cases where you will want to make sure 
there is at least something in all the TestChar fields. 

This approach can also be used to locate multiple characters. If 
you enter for example, in the TestChar field, that exact combina¬ 
tion will be located if it exists. The value reported by the position calcu¬ 
lation will be the position of the first character of the group of charac¬ 
ters. This works for ‘P. O. Box’, for example, and points out all records 
that contain that particular combination. Note that you eire not limited 
to ignored characters. 

You can, of course, add a separate test equation field for each data 
field you want to examine. And there are some advantages to doing it 
that way. But another interesting variation is to expand a single posi¬ 
tion equation to cover more than one field. You can use an if state¬ 
ment to accumulate data about those fields in a record that contain 
the test character (s). 
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(continued) 


However, since the position function yields a numeric answer, it 
is even easier to simply add together a position function for each 
desired field. The figure below illustrates one such calculation that 
tests the Organization, Street, and City fields. The resulting number 
itself will not be very informative, especially if the test character exists 
in more than one field in a record. But finding records that need to be 
fixed is easy. 

The last figure on 

_ Field Definition _ this page shows the 

Calculation Result Is: LocateTest field having 

LocateTest = O Teat ® Number O Date found the asterisk char- 

position (Organization,TestChar,!) + position (Street,TestChar,1) + acter (specified in the 

position (City,TestChar,1 ) TestChar field) that is in 

the Street field. 


PrefiH 

FName 

LName 

Organization 

Location 

Street 

City 

State 


Qd)®® 

Q0®0 

00 ®® 

0000 

000 



Records: 
51 


FName Joe 
LName Eroeger 

Organization Elk. Horn Publishing 

Street 64 Penny Lane Suite *A 
City Aromas 

State CA Zip 95019 

LocateTest 21 
TestChar * 


nrzzzzr Clearly, this type of 

0 ^ character searching is 

auerage 0 ^ ^ universal panacea, 

count 0 11 j j r 

ijgig j j We really do need for 

OateToTeut 0 || FileMaker to have a gen- 
day 0 ^ eral capability to handle 

_ any keyboard character. 

1 \ Cancel j many cases it will be 

J| a disadvantage to have 
to create a calculation to 
carry out the desired search. The cal¬ 
culation can take a long time in a data¬ 
base with, say 20,000 records. 

Sometimes moving the data to a 
word processor allows searching all of 
it for specific items - a task that is of¬ 
ten difficult to do in the database. Still, 
1 regard this technique as another good 
addition to the ever-expanding arsenal 
of FileMaker working tools and weap- 
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